Improve versification error detection #362
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #362 +/- ##
==========================================
- Coverage 72.51% 72.51% -0.01%
==========================================
Files 423 423
Lines 35933 35945 +12
Branches 4960 4962 +2
==========================================
+ Hits 26058 26066 +8
- Misses 8779 8781 +2
- Partials 1096 1098 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@ddaspit If we can, I'd like to get this in before the QA release. (I'm thinking Monday instead of today?). This error could cause entire builds to fail and the error message that you get from SIL.Scripture is not very helpful (unlike other exceptions thrown when parsing the USFM). |
ddaspit
left a comment
ddaspit
left a comment
There was a problem hiding this comment.
@ddaspit reviewed 2 of 2 files at r1, all commit messages.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on @Enkidu93)
src/SIL.Machine/Corpora/UsfmVersificationErrorDetector.cs line 169 at r1 (raw file):
{ string verseString = _actualVerse == -1 ? "" : verse.ToString(); return $"{Canon.BookNumberToId(_bookNum)} {chapter}:{verseString}";
One thing we should watch out for whenever converting a number to a string is that the current culture is used to do the conversion, so in some cases, you can get an unexpected string representation of a number. I think it is probably okay here, since these numbers should only be positive integers, which I believe are consistent across cultures. Whenever converting a number to a string, I try to remember to use the invariant culture.
This comes out of a problem John Nystrom experienced with a project. While I was in the code, I also made some other small tweaks.
This will need to be ported to machine.py.
This change is